home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 6396 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: soap.news.pipex.net!pipex!usenet
  2. From: m.hendry@dial.pipex.com (Mathew Hendry)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: Speed: 68040 vs. 68060
  5. Date: Mon, 26 Feb 96 16:56:06
  6. Organization: Private node.
  7. Distribution: world
  8. Message-ID: <19960226.43B8E8.EF50@ai038.du.pipex.com>
  9. References: <4foi00$60t@gondor.sdsu.edu> <3125E74D.3390@gih.no> <19960223.425E10.10CBD@an100.du.pipex.com> <19960225.7AF9790.E534@asd10-22.dial.xs4all.nl> <19960226.477570.1832@an174.du.pipex.com> <4grotj$8q3@serpens.rhein.de> <19960226.7B42F98.E8D9@asd06-03.dial.xs4all.nl>
  10. NNTP-Posting-Host: ai038.du.pipex.com
  11. X-Newsreader: TIN [AMIGA 1.3 950726BETA PL0]
  12.  
  13. Jeroen T. Vermeulen (jtv@xs4all.nl) wrote:
  14. : In article <4grotj$8q3@serpens.rhein.de> mlelstv@serpens.rhein.de (Michael van Elst) writes:
  15. : > m.hendry@dial.pipex.com (Mathew Hendry) writes:
  16. : >
  17. : > >BTW, running the BYTEMarks in a multitasking environment is actually likely
  18. : > >to show the Amiga in a good light, because AmigaOS has much lower task
  19. : > >switching overheads than many other multitasking OSs...
  20. : >
  21. : > Right.
  22. : 
  23. : Not necessarily in this case.  What I meant is that the timing routines may
  24. : include time spent on other tasks.
  25.  
  26. That's irrelevant. The intention is to see how long the algorithms take on a
  27. real system (in real time, not in CPU time). On a real system, running a real
  28. application, you will also have other tasks "stealing" CPU time, which
  29. increases the real time taken to complete a task.
  30.  
  31. : As for task-switch overhead:  You'll note that BYTE's comparison base has *no*
  32. : task-switch overhead because it doesn't multitask.  It's just a plain Intel box
  33. : single-tasking in 32-bit mode with essentially no OS at all.
  34.  
  35. Fair enough, but the base is intended as only that - a base, for comparison with
  36. results on other machines. Any useful OS / machine combination which you test
  37. will also have task switching overheads. The baseline merely serves a reference
  38. to put the benchmarks in a sensible range.
  39.  
  40. : > >: As for FP performance, I didn't look through the source all that closely but it
  41. : > >: seemed to me that the FP tests happened to hammer mainly on the few FP
  42. : > >: instructions that aren't implemented on the 040 (and are trapped by SW
  43. : > >: emulation).  Here too the Amiga could be getting results that can be said to be
  44. : > >: artificially low by a very large factor.
  45. : >
  46. : > >Again, we're talking about the real world here. The algorithms were selected
  47. : > >to mirror those common in real applications. Do you think that they are not
  48. : > >representative?
  49. : >
  50. : > The binaries might be not representative. If compiled for the right CPU there
  51. : > shouldn't be a huge emulation overhead.
  52. : 
  53. : Whether emulation code is inlined or not, there is a lot of overhead involved
  54. : simply in computing the expected results in software.  I compiled for the 040 in
  55. : both cases but that doesn't take away the fact that the tests may be focused on
  56. : an extremely unlucky part of the 040 FPU instruction set.
  57.  
  58. Unlucky, maybe. But do you think that this focus is _unrepresentative_ of real
  59. applications?
  60.  
  61. If it is representative, then you will of course be similarly unlucky in
  62. that applications will focus on the same instructions. People who write
  63. applications use the same compilers as those who compile the benchmarks, after
  64. all.
  65.  
  66. If it isn't representative, then you have more of an argument.
  67.  
  68. -- Mat.
  69.